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1.  Introduction 


This  is  the  Final  Report  for  Phase  One  of  the  BBN  Laboratories  Knowledge  Acquisition  Project.  This  research  was 
supported  by  the  Defense  Advanced  Research  Projects  Agency  of  the  Department  of  Defense  and  was  monitored  by 
the  Rome  Air  Development  Center  (RADC)  under  contract  number  F30602-85-C-0005. 

The  goal  of  this  project  was  to  create  a  useable  and  extensible  knowledge  engineering  environment  that  will  be 
capable  of  handling  very  large  knowledge  bases,  support  experiments  with  knowledge  engineering  techniques  and 
implement  a  useable  system  for  knowledge  acquisition  and  maintenance.  During  Phase  One  of  this  project  we  have 
created  the  KREME  Knowledge  Representation  Editing  and  Modeling  Environment.  KREME  is  an  extensible 
experimental  environment  for  developing  and  editing  large  knowledge  bases  in  a  variety  of  representation  styles.  It 
provides  tools  for  effective  viewing  and  browsing  in  each  kind  of  representation,  automatic  consistency  checking, 
macro-editing  facilities  to  reduce  the  burdens  of  large  scale  knowledge  base  revision  and  some  expenmental 
automatic  generalization  and  acquisition  facilities. 

Among  the  planned  extensions  to  KREME  are: 

•  The  Procedure  Editor 

•  A  KEE  Interface 

•  The  Addition  of  Boolean  Connectives  to  Slot  Restrictions 

•  Extension  of  the  Macro  Editor 

We  are  currently  in  the  process  of  extending  the  value  restriction  language  to  permit  more  complex  forms  containing 
conjunctions,  disjunctions  and  negations,  based  on  the  restriction  language  for  KEE,ml  frames  [6].  This  effort 
should  result  in  an  extended  classifier,  as  well,  capable  of  maintaining  consistency  among  frames  in  the  KEE  class 
of  frame  languages 

During  Phase  Two  we  will  also  be  developing  expenmental  kinds  of  automatic  knowledge  acquisinon:  techniques 
for  generating  controlled  acquisition  dialogues,  procedures  to  automatically  transform  previously  acquired 
knowledge  for  use  m  new  tasks,  and  techniques  for  learning  by  analogy  and  from  examples 
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2.  Overview  of  the  BBN  Knowledge  Acquisition  Project 


Our  goal  has  been  to  develop  an  environment  in  which  the  problems  of  knowledge  acquisition  faced  by  even 
knowledge  engineer  attempting  to  build  a  large  expert  system  are  minimized.  We  believe  both  knowledge  engineers 
and  subject  matter  experts  with  some  knowledge  of  basic  knowledge  representation  techniques  will  find  it  easy  to 
use  KREME  to  acquire,  edit,  and  view  from  multiple  perspectives  knowledge  bases  that  are  several  times  larger 
(i.e.,  5*10,000  concepts)  than  those  found  in  most  current  systems. 

KREME  attempts  to  deal  with  the  inextricably  related  problems  of  knowledge  representation  and  knowledge 
acquisition  in  a  unified  manner  by  organizing  multiple  representanon  languages  and  multiple  knowledge  editors 
inside  of  a  coherent  global  environment.  A  key  design  goal  for  KREME  was  to  build  an  environment  in  which 
existing  knowledge  representation  languages,  appropriate  to  diverse  types  of  knowledge,  could  be  integrated  and 
organized  as  components  of  a  coherent  global  representation  system.  The  current  KREME  Knowledge  Editor  can 
be  thought  of  as  an  extensible  set  of  globally  coherent  operations  that  apply  across  a  number  of  related  knowledge 
representation  editors,  each  tailored  to  a  specific  type  of  knowledge.  Our  approach  has  been  to  integrate  existing 
frame  and  rule  representation  languages  in  an  open  ended  architecture  that  allows  the  extension  of  each  of  these 
languages  In  addition,  we  have  provided  for  the  incorporation  of  additional  representanon  languages  to  handle 
additional  types  of  knowledge 

Our  approach  to  consistency  maintenance  has  been  to  develop  a  knowledge  integration  subsystem  that  includes  an 
automatic  frame  classifier  and  faciboes  for  inter-language  consistency  maintenance  The  frame  classifier 
automatically  maintains  logical  consistency  among  all  of  the  frames  or  conceptual  class  definitions  in  a  KREME 
frame  base.  In  addition,  it  can  discover  implicit  class  relationships,  since  it  will  determine  when  one  definition  is 
logically  subsumed  by  another,  even  when  the  knowledge  engineer  has  not  explicitly  stated  that  relationship.  The 
inter-language  consistency  maintenance  facility  checks  for  inconsistencies  in  references  to  frames  in  knowledge 
bases  specified  using  other  representation  languages  (e  g.,  rules,  procedures). 

A  second  important  area  of  investigation  in  developing  the  KREME  editing  environment  has  been  the  attempt  to 
provide  facilities  for  large-scale  revisions  of  a  knowledge  base.  Our  experience  indicates  that  the  development  of  an 
expert  system  inevitably  requires  such  systematic  revisions  of  the  developed  representation.  This  is  often  caused  by 
the  addition  or  redefinition  of  a  task  the  system  is  to  perform.  These  kinds  of  systematic  changes  to  a  knowledge 
base  generally  require  painstaking  piecemeal  revision  of  each  affected  element,  one  at  a  time  Our  initial  approach 
has  been  to  provide  a  macro-editing  facility,  in  which  the  required  editing  operations  can  be  demonstrated  by 
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example  and  applied  to  specified  sets  of  knowledge  structures  automatically.  A  library  of  genenc  macro-editing 
operations  for  tbe  most  common  and  conceptually  simple  (though  potentially  difficult  to  descnbei  operations  will  be 
developed  during  Phase  Two  of  the  project. 

Finally,  we  have  begun  to  investigate  techniques  for  automatic  generalization  of  concepts  defined  in  a  knowledge 
base.  We  will  briefly  describe  these  experiments  as  well,  in  Section  8. 

Underlying  the  entire  KREME  system  is  a  strong  notion  of  meta-level  knowledge  about  knowledge  representation 
and  knowledge  acquisition  The  representation  languages  were  implemented  based  on  a  careful  decomposition  of 
existing  knowledge  representation  techniques  and  implemented  as  combinable  objects  using  FLAVORS  [7  J.  By 
organizing  this  meta-level  knowledge  base  modularly.  behavioral  objects  implementing  such  notions  as  mhemance 
and  subsumption  could  be  "mixed  m"  to  a  variety  of  representational  subsystems  making  the  incorporation  of  new 
representations  and  their  editors  reasonably  straightforward  That  is.  each  object  in  the  meta-knowledge  base 
encodes  some  aspect  of  a  traditional  representational  technique,  and  is  responsible  for  its  own  display,  editing  and 
internal  forms. 
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3.  The  KREME  Knowledge  Representation  Editing  and  Modeling 
Environment 


3.1  Functional  Description 

The  KREME  family  of  knowledge  editors  currently  consists  of  three  major  editor  modules:  a  frame  editor,  a  rule 
editor,  and  a  procedure  editor.2  (See  figure  3-1  )  KREME  also  includes  a  large  toolbox  of  editing  techniques  that 
are  shared  among  the  editor  modules  This  section  will  describe  the  global  environment  and  toolbox,  later  sections 
will  describe  the  individual  editors.  Sections  3.3  through  3.5  provide  a  discussion  of  the  user  interface  Readers  who 
require  more  detail  should  consult  KREME  A  User's  Introduction ,  BBN  Report  No.  6508. 


Procedure  Representation 
System 


Rule  Representation 
System 


Frame  Representation 
System 
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3.2  Basic  Editing  Environment 

Each  type  of  representation  included  in  the  system  has  defined  for  it  one  or  more  editor  views.  A  view  is  a 
collection  of  windows  appearing  together  on  the  screen  Each  window  displays  some  aspect  of  the  particular  piece 
of  knowledge  being  edited  and/or  a  set  of  editing  operaoons  on  it.  When  the  user  desires  to  enter  or  edit  a  specific 
piece  of  knowledge,  the  system  opens  the  most  appropriate  view  for  the  type  of  knowledge  and  the  editing  operation 
requested.  Typically,  any  aspect  of  the  know  ledge  being  edited  can  be  changed  or  viewed  in  more  detail  simply  by 
pointing  at  it.  This  organization  allows  knowledge  to  be  viewed  by  the  user  from  multiple  perspectives  and  at  more 
than  one  level  of  detail 

The  editor  maintains  a  level  of  mdirecoon  between  the  knowledge  being  edited  and  the  representation  of  that  piece 
of  knowledge  in  the  know  ledge  base.  This  is  jw.oniplishe  J  h  •  j  roe.  hom-.ni  like  that  ol  test  ednor  buffers  Changes 
are  always  made  to  editor  definition  oh  <\:.\  whnfi  .uv  di'tin.'  tr  -m  the  so Responding  obiects  in  the  actual 
knowledge  base.  The  stack  or  list  of  the  active  definiti  on  .'hie.n  >  .isiblc  to  the  user  The  top  item  in  this 

list  is  the  definition  currently  being  viewed  and  edited  The  use:  i-  tree  '•  m  xlitv  the  current  definition  in  any  way 
without  directly  affecting  the  knowledge  base  Onl  when  ifi.  modified  definition  is  to  be  placed  into  the 
knowledge  base  is  a  defining  function  appropriate  to  the  type  .  t  knowledge  e  g  classification  tor  concepts  and 
roles),  executed  and  the  know  ledge  base  modified 

Since  the  editor  stack  is  always  visible,  it  provides  one  convenient  method  for  browsing  The  user  may  point  at  any 
definition  item  currently  in  the  stack  The  ohie^t  will  then  be  displayed  in  the  same  editor  view  as  when  it  was  Iasi 
edited. 

A  number  of  window  subsystems  or  tools  have  been  developed  and  incorporated  into  the  KREME  editor  to  make 
editing,  viewing  and  browsing  in  know  ledge  bases  easier  and  faster  They  are  descnbed  below 

3.3  The  Grapher 

KREME  is  equipped  with  a  general  graphing  facility  that  rapidly  draws  lattices  of  nodes  and  links  Its  main  use  is  to 
provide  a  dynamically  updated  display  of  a  concept  or  role  and  its  place  in  the  specialization  or  inhentance 
hierarchy  When  editing  a  concept  in  the  Main  Concept  Editing  View  or  the  Big  Concept  Graph  View .  or  when 
editing  a  role,  KREME  automatically  displays  all  of  that  object's  abstractions  and  specializations  More  abstract 
objects  are  displayed  to  the  left  of  the  current  editor  object,  and  more  specialized  objects  to  the  right 

As  shown  in  figure  3-2.  the  current  editor  object  appears  as  a  black  nixie  with  white  letters  All  other  objects  appear 
as  nodes  w  ith  a  white  background  Obiects  that  are  defined  as  pnmm\e  are  indicated  by  bold-edged  boxes  Nodes 
that  have  been  modified  (edited  but  not  reclassified  >  have  a  grey  background 
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3.3.1  Panning  the  Graph 

The  grapher  can  display  a  graph  much  larger  than  the  window  through  which  it  is  viewed.  To  see  a  part  of  the 
network  that  is  off  the  screen,  the  user  points  w  ith  the  mouse  at  some  point  on  the  graph  window  not  containing  a 
node,  bolds  the  left  button  down  and  drags  the  mouse  To  speed  pan ,  the  user  holds  down  the  middle  mouse  button. 

3.3.2  The  Overview  Graph 

Clicking  the  right  button  once  over  an  empty  part  of  the  graph  window  will  make  the  Graph  Operations  Menu 
appear.  If  the  user  clicks  overview ,  a  miniature  version  of  the  full  lattice  will  appear  in  a  black  region  in  the  upper 
left  comer  of  the  graph  window  (as  in  figure  3-2).  This  overview  shows  a  miniature  version  of  the  full  network 
The  visible  region  of  the  graph  is  indicated  by  a  white  rectangle  If  the  user  pans  with  the  mouse  over  the  main 
graph  window,  this  white  rectangle  will  follow  the  mouse  movements.  All  of  the  mouse  operations  available  on 
nodes  in  the  main  window  will  also  work  on  nodes  in  this  window.  The  name  of  the  node  being  pointed  at  is 
indicated  in  the  mouse  documentation  window  .  The  overview  window  also  can  be  used  to  pan  the  main  graph 
window.  The  overview  is  turned  off  by  bringing  up  the  Graph  Operations  Menu  and  clicking  the  command 
overview. 

3.3.3  The  Graph  Operations  Menu 

The  other  options  in  the  Graph  Operations  menu  shown  in  figure  3-3  are: 

•  hardcopy  -  Sends  a  copy  of  the  full  graph  of  the  lattice  to  the  printer. 

•  style  menu  -  Allows  the  user  to  choose  the  font  style  and  size  of  characters  used  for  nodes  on  the  graph 
Smaller  fonts  are  useful  to  see  more  of  large  networks  at  once. 

•  find  node  -  Prompts  for  the  name  of  an  object  on  the  graph,  and  centers  that  node  on  the  graph  w  indow 
It  also  draws  a  circle  around  the  node  so  that  the  user  can  find  it  more  easily.  The  circle  disappears  as 
soon  as  the  graph  is  panned. 

•  overview  -  Switches  the  overview  graph  between  visible  and  invisible. 

•  orientation  -  Switches  the  onentation  of  the  graph.  Normally,  the  lattice  is  drawn  from  left  to  right 
This  command  will  cause  the  graph  to  be  redrawn  from  the  top  of  the  screen  dowm,  and  vice  versa. 

•  speed  pan  -  This  command  pops  up  the  speed  panning  box  without  having  to  hold  down  the  mouse 
button.  In  this  mode,  clicking  any  mouse  button  will  make  it  go  away. 

•  redraw  graph  -  Redraws  the  current  graph. 
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Figure  3-3:  The  Graph  Operations  Menu 

3.3.4  The  Graph  Node  Command  Menu 

Normally,  the  KREME  Grapher  displays  only  the  abstractions  and  specializations  of  the  current  editor  object, 
because  KREME  was  designed  to  work  with  the  very  large  lattices  characteristic  of  very  large  kno*  ledse  bases. 
The  Grapher  provides  a  number  of  options  to  enable  users  to  tailor  the  display  to  see  more  (or  less)  than  KREME 
normally  displays  on  such  graphs 

Whenever  the  mouse  is  over  a  node  on  a  graph,  the  mouse  documentation  window  show  s  the  name  of  the  node, 
followed  by: 

L:Edit  this  node.  M: Graph  Relatives  R:Menu  of  Editing  Options 

Clicking  the  left  mouse  button  causes  KREME  to  make  the  object  pointed  to  the  top  editor  stack  item.  This  is  an 
extremely  convenient  way  of  browsing  through  large  concept  networks  quickly,  and  focusing  on  different  portions 
of  such  a  network.  If.  however,  the  user  wishes  to  continue  editing  the  concept  that  he  is  currently  viewing,  but  see 
more  (or  less)  of  the  network  around  that  concept  or  some  other  concept  on  the  same  graph,  he  can  use  the  Graph 
Relatives  Menu  found  by  clicking  the  middle  mouse  button  over  any  graph  node. 

The  Graph  Relatives  Menu,  exposed  by  clicking  the  middle  button  over  a  node,  contains  the  following  commands: 

•  Graph  Parents  -  causes  all  abstractions  of  the  node  clicked  on  to  be  added  to  the  displayed  graph 

•  Graph  Children  -  causes  all  specializations  of  the  node  clicked  on  to  be  added  to  the  displayed  graph. 

•  Hide  Children  -  causes  all  specializanons  of  the  node  clicked  on  to  be  removed  from  the  graph,  unless 
they  are  also  children  of  some  other  node 
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•  Hide  Node  and  Children  -  causes  the  node  clicked  on  and  us  children  to  be  removed  from  the  graph 

3.3.5  Editing  a  Network  from  a  Graph 

Clicking  the  right  button  over  a  graph  node  causes  yet  another  menu  of  options  to  be  exposed,  the  Concept  Graph 
Edit  Options  Menu.3 

This  menu  contains  the  following  options  for  concepts: 

•  Show  Definition  -  This  option  causes  the  textual  (LISP)  form  of  the  concept's  defimuon  to  be 
displayed  over  the  Graph  Window. 

•  Kill  Concept  -  This  causes  the  concept  pointed  to  to  be  removed  from  the  knowledge  base.  It  has  the 
same  effect  as  the  Kill  Concept  command  in  the  local  command  menu  window,  except  that  it  works 
when  the  user  is  not  currently  editing  the  concept  he  wishes  to  kill. 

•  Rename  Concept  -  This  command  prompts  for  a  new  name  for  the  concept  pointed  to,  and  immediately 
replaces  all  references  to  that  name  with  the  new  name  throughout  the  knowledge  base. 

•  Delete  Parent  -  This  command  prompts  for  the  name  of  a  parent  and  then  deletes  that  parent  from  the 
list  of  defined  parents  of  the  concept  initially  pointed  to  It  also  switches  KREME  to  editing  the 
concept  modified,  so  that  it  can  then  be  reclassified 

•  Add  Parent  -  This  command  also  prompts  for  a  parent,  adds  the  concept  named  to  the  list  of  defined 
parents  of  the  concept,  and  sw  itches  to  editing  the  modified  concept. 

•  Splice  Out  Parent  -  This  command  prompts  for  a  parent,  and  removes  that  parent  from  the  list  of 
defined  parents  of  the  concept,  replacing  it  with  that  concept's  parents.  Again,  the  editor  is  switched  to 
a  view  of  the  modified  concept. 

3.4  Editing  in  the  State  Window 

The  state  window  of  the  Main  Concept  Editing  View  displays  basic  information  about  the  concept  currently  being 
edited.  The  top  line  displays  the  name  of  the  concept,  and  any  synonyms  or  alternate  names  for  that  concept.  The 
name  of  the  concept  can  be  changed  by  clicking  on  the  word  Concept:  and  entering  a  new  name 


The  second  lure  of  the  display  show  s  w  hether  the  concept  is  defined  as  primitive  or  not.  and  whether  the  concept  has 
been  classified  or  modified  since  classification  Clicking  on  the  word  Primitive:  causes  the  concept  to  be  marked 
primitive  if  it  was  not.  and  vice  versa. 

The  third  line  displays  the  both  the  direct  and  defined  parents  of  the  concept,  after  the  word  Specializes:  Defintd 
parents  are  concepts  that  the  user  specifies  as  abstractions  of  the  concept.  Direct  parents  are  concepts  that  may  or 
may  not  have  been  defined  as  parents  of  the  current  one,  but  have  been  determined  by  the  classifier  to  subsume  the 
class  denoted  by  this  concept  and  not  have  an\  specializations  that  also  subsume  this  concept  On  the  Concept 
Graph,  the  direct  parents  of  a  concept  are  the  ones  w  ith  direct  links  to  it 


^On  graphs  of  roles  the  Role  Graph  Fdit  < Ipttons  Menu  appears  nh  essential!)  the  same  commands  tor  roles,  except  as  noted 
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This  Specializes:  list  should  be  read  as  follows:  Concepts  that  are  unmarked  are  both  defined  parents  and  direct 
parents.  Concepts  that  are  defined  parents  but  not  direct  parents  are  prefixed  by  a  Concepts  that  are  direct 
parents  but  not  defined  parents  are  prefixed  by  a  The  user  can  easily  add  a  parent  to  the  set  of  defined  parents 
of  the  concept. 

3.5  Editing  in  the  Table  Edit  Window 

Normally,  the  table  edit  window  in  Main  Concept  View  displays  the  set  of  Local  Slots  of  the  concept,  that  is. 
those  slots  which  are  defined  locally  by  this  concept  and  not  inherited  from  above.  The  columns  in  the  table  are 
labeled  "Defined  by".  "Role",  "Number  Restriction",  "Value  Restriction",  "Default",  and  "Description". 

Clicking  (with  the  left  mouse  button)  on  the  command  All  Slots  in  the  table  edit  command  window  causes 
KREME  to  display  both  local  and  inhented  slots.  In  this  display,  local  slots  are  indicated  by  the  word  ‘LOCAL*  in 
the  "Defined  by"  column  of  the  table.  Slots  inherited  from  a  parent  show  the  name  of  that  parent.  Slots  formed  by 
combining  the  value  restrictions  and/or  number  restrictions  of  several  parents  are  indicated  by  the  word 
•CLASSIFIER*.  When  the  table  window  is  displaying  all  of  the  concept’s  slots,  the  user  can  return  to  viewing  just 
the  local  ones  by  clicking  the  command  Local  Slots. 

Whenever  the  Table  Edit  Window’  shows  slots  of  the  current  concept,  the  user  can  edit  those  slots  or  add  new  ones. 
To  change  the  slot  name,  value  restriction,  number  restriction,  default,  or  descnption  of  a  slot,  the  user  simply  clicks 
the  left  mouse  button  over  the  thing  to  be  changed,  and  will  be  prompted  for  a  replacement.  For  all  but  number 
restrictions,  the  nght  button  will  pop  up  a  menu  that  includes  the  commands:  Change  the  part  of  the  slot  pointed  to. 
Show  Definition  of  the  concept  or  role  pointed  to.  Edit  Definition  of  that  concept  or  role,  or  pop  up  a  Graph  of  its 
abstractions  and  specializations.  When  pointing  to  the  slot  name,  in  the  column  labeled  "Role",  the  user  can  also 
Rename  Role,  that  is.  change  the  name  of  the  role,  and  all  references  to  it  in  the  knowledge  base. 

When  the  mouse  is  over  a  fine  in  the  slot  table,  and  the  entire  line  is  encircled  by  a  box.  the  nght  mouse  button  can 
be  used  to  get  a  menu  of  Delete  Slot.  Copy  Slot  to  another  concept,  and  Move  Slot  to  another  concept.  For  the  last 
two,  KREME  prompts  for  the  name  for  the  concept  to  move  or  copy  the  slot  to. 
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3.5.1  Adding  New  Slots 


Report  So.  6543 


Whenever  the  slots  table  window  is  visible,  as  in  the  Main  Concept  Editing  View,  the  user  can  add  new  local  slot 
definitions.  A  new  slot  is  added  to  the  defined  slots  of  the  concept  with  the  Add  Slot  command.  When  tlus 
command  is  issued,  the  system  prompts  for  a  role  name,  a  value  restriction,  a  number  restriction  and  a  default  form 
Any  of  these  items  can  be  entered  by  typing  or  by  pointing  to  the  desired  name  or  form  if  it  is  visible 

If  a  role  or  concept  named  in  a  role  restriction  or  default  does  not  exist,  the  system  will  offer  to  make  one  with  the 
name  given,  and  proceed  to  pop  up  the  defining  form  for  that  object.  When  the  user  is  finished  filling  out  the  form, 
he  clicks  Define,  and  KREME  will  continue  to  ask  for  the  rest  of  the  new  slot's  features. 

When  the  user  has  finished  adding  and  modifying  the  slots  of  a  concept,  he  should  always  make  the  changes 
permanent  with  the  Classify  Concept  command 

3.5.2  Modifying  the  Table  Edit  Window 

The  appearance  of  Table  Edit  Windows  can  be  modified  in  several  ways.  The  tables  are  scrollable  in  both  the 
up-down  and  left-nght  directions. If  the  user  does  not  wish  to  see  some  columns  of  the  table,  they  can  be  selectively 
removed. 

3.5.3  Changing  the  Contents  of  the  Table  Window 

Since  there  is  not  enough  room  in  the  Main  Concept  Editing  View  to  display  all  of  a  concepts  defining  features  at 
one  time,  the  contents  of  the  Table  Edit  Window  can  be  changed  to  display  those  other  features  To  do  this,  the  user 
must  use  the  mouse  to  find  the  table  window  contents  menu  This  menu  is  available  wherever  there  is  nothing  else 
under  the  mouse  while  still  inside  the  table  window .  the  user  will  know  he  has  found  it  because  the  mouse 
documentation  window  will  show  the  words: 

R:  Change  the  contents  of  this  table. 

When  the  user  clicks  the  right  button,  he  will  see  the  following  menu  options: 

•  Slots  -  Displays  the  table  of  this  concept  's  slots,  as  described  above. 

•  Inverse  Restrictions  -  Displays  a  table,  essentially  like  the  slots  table,  but  of  all  of  the  slots  displayed 
are  slots  of  other  concepts  that  use  the  current  concept  as  their  value  restriction.  This  table  is  useful 
when  tracing  references  to  a  concept  in  other  concepts.  When  this  table  is  displayed,  the  table  edit 
command  window  will  be  empty.  Some  of  the  editing  options  described  for  the  slots  table  will  not 
work  here. 

•  Slot  Equivalences  -  This  table  displays  the  slot  equivalences  of  the  current  editor  concept  This  table 
has  only  three  columns.  "Defined  by".  "Path  1"  and  "Path  2".  The  two  paths  are  designated  as 
denoting  the  same  object  Since  slot  equivalences  can  be  inherited,  their  source  is  also  indicated  in  the 
table,  in  the  column  "Defined  by”  When  this  table  is  visible,  the  table  edit  command  window  will 
show  the  commands  Local  Equivalences.  All  Equivalences,  and  Add  Equivalence  The  first  two  just 
change  which  equivalences  are  displayed  The  last  prompts  for  two  slot  paths  that  should  be  made 
equivalent 
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•  Disjoint  Concepts  -  This  table  is  just  a  one  column  list  of  all  of  the  concepts  that  are  defined  to  be 
disjoint  from  the  one  currently  being  edited.  When  this  table  is  visible,  the  Table  Edit  Command 
Window  will  display  the  commands  Add  Disjoint  Class.  Local  Disjoint  Classes,  and  All  Disjoint 
Classes. 

3.6  Files  and  Multiple  Language  Support 

All  definitions  manipulated  by  the  editor  are  read  and  stored  in  lisp-readable  text  files  of  defining  forms.  Since 
these  files  contain  formatted  lisp  forms,  they  are  user-readable,  and  can  be  edited  offline  using  an  ordinary  text 
editor.  In  fact,  KREME  can  as  easily  read  files  that  were  developed  independently  using  a  text  editor  or  some  other 
frame  editor 

Files  are  read  in  using  the  LOAD  command  A  file  can  be  loaded  into  a  blank  KREME  knowledge  base  or  can  be 
loaded  on  top  of  an  already  existing  knowledge  base.  This  mechanism,  which  relies  heavily  on  the  the  frame 
classifier  to  maintain  consistency,  enables  KREME  to  organize  information  from  mulnple  knowledge  bases  to  create 
a  single  unified  w  hole. 

KREME  currently  reads  and  writes  definitions  in  either  its  own  frame  language  syntax  or  N1KL  syntax  This 
flexibility  has  made  it  possible  for  KREME  to  be  used  regularly  to  examine  and  update  a  knowledge  base  of 
approximately  1000  roles  and  concepts  for  the  IRl'S/JANUS  natural  language  interface  that  w  as  built  using  MKL 
KREME  can  also  read  files  of  MSG  (the  frame  language  of  the  STEAMER  [21]  system)  defining  firms,  providing 
access  to  the  extensive  STEAMER  knowledge  base  of  concepts  and  procedures.  We  are  currently  building  an 
interface  to  files  of  KEE  frame  definitions 

This  multiple  language  handling  facility  is  a  crucial  feature  of  KREME  A  library  of  input  translation  programs  will 
enable  a  knowledge  base  builder  using  KREME  to  draw  upon  previously  exisnng  knowledge  bases  to  create  new 
knowledge  bases. 
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4.  The  KREME  Frame  Editor 

This  section  will  describe  the  KREME  knowledge  editor  for  a  frame  representation  language. 

4.1  The  KREME  Frame  Language 

A  number  of  frame  languages  have  been  developed  in  recent  years  to  support  AI  systems  [11.2.  17.  9.  3.  6.  8]. 

These  languages  have  been  well  researched  and  extensively  tested,  aod  our  most  important  criteria  for  a  suitable 

frame  representation  language  were  that  it: 

1  Allowed  mulnple  inheritance 

2.  Was  a  logically  worked  out  mature  language 

3.  Had  some  mechanism  for  internal  consistency  checking 

4.  Was  built  on  a  modular  object  oriented  base  so  that  the  language  could  be  decomposed  in  such  a  way  as  to 
make  it  easily  extensible. 

NIKL  (the  definitional  or  frame  language  component  of  KL-TWO)  [9.  14,  20]  seemed  an  ideal  candidate  It  is  a 
fully  worked  out  frame  representation  language  that  allows  multiple  inheritance,  is  reasonably  expressive  and. 
perhaps  most  importantly ,  was  designed  to  work  effectively  with  an  automatic  classification  algonthm  that  could  be 
easily  adapted  to  provide  a  powerful  mechanism  for  consistency  checking  and  enforcement  during  know  ledge  base 
development.  However,  no  object-onented  implementauon  of  NIKL  existed,  and  the  NIKL  classifier  was  not 
designed  to  allow  modification  and  reclassification  of  previously  defined  concepts.  A  second  frame  language, 
known  as  MSG.  had  been  built  as  pan  of  BBS's  STEAMER  project  and  is  object  onented  in  both  of  the  above 
senses. 

To  develop  KREME.  we  elected  to  reimplement  NIKL  as  an  object  onented  language  using  MSG  as  a  guide  The 
NIKL  data  structures  were  decomposed  into  a  modular  hierarchy  of  flavor  defirunons.  and  the  KREME  frame 
language  was  then  built  out  of  these  flavors  This  enabled  us  to  incorporate  the  sophisticated  instantiation 
mechanism  of  MSG  with  minimal  effort  In  the  process,  we  were  also  able  to  implement  a  modular  version  of  the 
NIKL  classifier  algonthm.  This  provided  the  kind  of  reclassification  capability  required  for  a  knowledge  editing 
environment  and  anticipated  the  extension  of  the  classifier  to  deal  with  the  richer  semantics  of  languages  like 
Intellicorp's  KEE  [6] 
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4.1.1  Frame  Language  Syntax 

The  remainder  of  this  section  will  briefly  describe  the  basic  definitional  syntax  of  the  KREME  Frame  language.  As 
this  syntax  closely  resembles  the  formal  syntax  of  NIKL  interested  readers  are  referred  to  [9]  for  more  detail 

Following  NIKL,  a  KREME  frame  is  called  a  concept.  Collections  of  concepts  are  organized  into  a  rooted 
inheritance  or  subsumption  lattice  sometimes  referred  to  as  a  taxonomy  of  concepts.  A  single  distinguished  concept, 
usually  called  THING,  serves  as  the  root  or  most  general  concept  of  the  lattice.  A  concept  has  a  name,  a  textual 
description,  a  primitiveness  flag,  a  list  of  concepts  that  it  specializes  or  is  subsumed  by,  a  list  of  slots,  a  list  of  slot 
equivalences,  and  a  list  of  concepts  that  it  is  disjoint  from 


77TT7777|| 

r\ 

<•  a 

► 


A 

S:  vj 

o 

/ 

V’ 
Ll 


The  lists  of  slots,  slot  equivalences  and  disjoint  concepts  are  collectively  referred  to  as  the  features  of  a  concept  If 
each  concept  can  be  thought  of  as  defining  a  unique  category,  then  features  of  the  concept  define  the  necessary 
conditions  for  inclusion  in  that  category.  If  a  concept  is  not  marked  as  primitive,  the  features  also  constitute  the 
complete  set  of  sufficient  conditions  for  inclusion  in  that  category  .4  A  concept  inherits  all  features  from  those 
concepts  above  it  in  the  lattice  (those  concepts  that  subsume  it.  and.  thus,  are  more  general)  and  may  define 
additional  features  that  serve  to  distinguish  it  from  its  parent  or  parents. 

Slots  (sometimes  called  role  restncnonsi  consist  of  a  role  or  slot  name,  a  value  restriction,  a  number  resmction  and 
an  (optional)  default  form.  The  value  restriction  specifies  the  class  of  concepts  allowed  as  values  for  that  slot  As  in 
NIKL.  value  restrictions  usually  specify  a  particular  concept. 

Slot  Equivalences  descnbe  slots  land  slots  of  slots)  that  by  definition  must  always  refer  to  the  same  entities 
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The  role  name  specified  for  each  KREME  slot  refers  to  an  object  called  a  role  Roles  in  KREME.  as  in  NIKL  and 
several  other  frame  languages  like  KR^TTON  [3].  and  KnowledgeCraft  [8],  are  actually  distinct,  first  class  objects 
that  form  their  own  disunct  taxonomy,  rooted  at  the  most  general  possible  role,  usually  called  RELATION  Roles 
descnbe  two  place  relations  between  concepts.  A  role  restriction  at  a  concept  is  thus  a  specification  of  the  w  ay  s  a 
given  role  can  be  used  to  relate  that  concept  to  other  concepts. 


‘Concepts  marked  as  primitive  (sometimes  reietred  lo  as  Sarurji  A'moj  >  base  no  complete  set  of  sufficient  conditions  For  esampic  an 
ELEPHANT  must,  bs  necessity  be  a  MAMMAL  but  sstthout  an  exhausttse  itst  of  the  attributes  that  distinguish  it  from  other  mammals,  it  must 
be  represented  as  a  primitive  concept  The  Jaw  of  ^  HITH  ELEPHANT v  or  the  other  hand,  might  be  completely  described  a*  a  ELEPHANT 
with  slot  COLOR  restricted  to  ^  HITL. 


16 


A  A  *p  »  A  » 


Report  No.  6543 


BBN  Laboratories  Incorporated 


4.2  Using  the  Frame  Editor 

The  KREME  frame  editor  has  five  views,  the  Main  Concept  Editing  View,  tbe  Alternate  Concept  Editing  View . 
the  Big  Graph  View  ,  and  the  Macro  Structure  Editor  View  Roles,  which  are  also  part  of  the  KREME  Frame 
language,  are  edited  with  the  Role  Editing  View .  In  this  section,  we  will  cover  the  details  of  the  edtong  operations 
available  in  the  first  three  of  these  views. 

4.2.1  Editing  in  the  Main  Concept  Editing  View 

Normally,  when  one  creates  a  new  concept  or  edits  a  concept  for  the  first  time.  KREME  makes  that  concept  the  top 
concept  on  the  Editor  Stack,  and  switches  to  display  the  Mam  Concept  Editing  View.  There,  KREME  displays  the 
concept  as  it  exists  at  that  time. 

Figure  3-2  shows  how  the  graph  window  immediately  displays  all  of  the  abstractions  and  specializations  of  the 
concept  being  edited,  the  state  window  shows  its  name,  whether  it  is  pnminve  or  not.  its  edit  state  (classified  or  not. 
modified  or  not),  its  parents,  and  a  textual  descnpnon.  The  table  window  simultaneously  displays  all  of  the 
concept's  locally  defined  slots. 

4.2.2  Frame  Editing  Operations 

Space  does  not  permit  a  full  descnpnon  of  the  functionality  of  the  KREME  frame  editor  so  we  will  vers  bnefiy 
touch  upon  a  few  of  us  more  important  operations 

Making  new  concepts.  The  .\>«  Concept  command  ui  the  global  command  menu  inmates  the  definition  of  a  new 
concept  that  is  ( 1 )  fully  specified  by  the  user.  (2  i  similar  to  some  already  defined  concepi.  or  (3)  a  specialization  of 
one  or  several  other  defined  concepts  When  the  initial  form  for  the  new  concept  has  been  specified  the  system 
creates  a  new  concepi  definition  for  it  and  shows  this  new  definition  in  the  main  concept  view  The  user  is  then  free 
to  add  details  (slots,  equivalences,  additional  parents,  etc  )  to  the  new  concept  definition,  classify  it.  or  edit  other 
concepts 

Adding  and  modifying  slots.  Whenever  the  w  indow  displaying  slots  is  visible,  slots  can  be  added  or  modified  A 
new  slot  is  added  to  the  defined  slots  of  the  concept  with  the  Add  Slot  command  Any  portion  of  a  slot  s  definition 
can  be  entered  by  typing  or  by  pointing  to  a  visible  reference  to  the  desired  item  When  a  role  or  concept  name  that 
is  not  defined  is  specified,  the  system  offers  to  make  one  with  the  name  given 

Users  may  modify  any  locally  defined  slot  or  inherited  slot  Slots  show  n  in  table  windows  are  modified  by  pointing 
at  the  appropriate  subform  and  then  either  typing  in  or  pointing  to  a  replacement  form.  Modify  ing  an  inherited  slot 
causes  the  new  definition  to  be  locally  defined 
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Adding  and  Deleting  parents.  The  system  displays  the  classifier  determined  parents  of  a  concept  in  two  places 
The  concept  graph  displays  them  as  part  of  the  abstraction  hierarchy  of  the  concept,  and  the  state  pane  indicates  both 
the  defined  and  direct  or  computed  parents  of  the  concept  3fier  the  word  "Specializes:".  Since  the  classifier  ma> 
have  found  that  the  concept  being  edited  specializes  some  concepts  more  specific  than  those  given  as  its  defined 
parents,  defined  parents  that  are  not  direct  parents  are  preceded  by  a  while  classifier  determined  parents  that 
were  not  defined  parents  are  preceded  by  a  "+". 

Adding  new  defined  parents  to  a  concept's  definition  is  done  by  clicking  on  the  word  "Specializes:1  in  the  state 
window  and  typing  a  concept  name  or  pointing  to  any  visible  concept.  Parents  can  be  deleted  by  clicking  on  their 
names  in  the  list  of  parents  displayed  in  the  state  w  indow 

Changing  names  and  killing  concepts  and  roles.  KREME  allows  the  user  to  change  the  names  of  concepts  and 
roles  or  to  delete  them  completely.  Name  changing  is  accomplished  simply  by  pointing  at  the  concept  or  role  s 
name  in  the  state  window  and  entering  a  new  name  The  Kill  command  splices  a  concept  out  of  the  taxonomy  by 
connecting  all  of  its  children  to  all  of  its  parents. 
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5.  Large-Scale  Revisions  of  Know  ledge  Bases 

As  knowledge  bases  grow  larger,  and  the  sets  of  tasks  that  intelligent  systems  are  called  upon  to  perform  expands, 
system  developers  will  need  automatic  methods  for  revising  and  reformulating  accumulated  knowledge  bases. 
Toward  this  end.  we  feel  that  it  is  important  to  find  ways  of  expressing  reformulations  of  sets  of  frames  and  other 
representations  and  to  begin  developing  facilities  supporting  the  generation  of  new  representations  from  old  ones 

We  are  taking  two  different  approaches  to  these  problems.  First,  we  have  developed  a  macro  facility  for 
reformulations  that  can  be  expressed  as  sequences  of  standard,  low-level  editing  operations  This  facility  allows 
users  to  use  an  example  to  define  editing  macros  that  can  be  applied  to  sets  of  frame  definitions  Second,  we  arc 
building  a  library  of  functions  providing  standard  editing  operations  that  cannot  be  defined  simply  as  sequences  of 
low  level  editing  operations.  Our  main  purpose  in  this  project  is  to  collect  and  categorize  a  number  ot  different 
kinds  of  knowledge  base  reformulations.  Our  hope  is  that  a  large  fraction  of  these  operations  can  be  conveniently 
descnbed  using  the  macro  facility .  as  it  is  more  accessible  to  an  expenmental  user  community  than  any  set  of 
"prepackaged"  uolmes.  and  can  be  more  responsive  to  the.  as  yet.  largely  unknown  special  needs  of  that  community 

5.1  The  Macro  and  Structure  Editor 

One  of  the  views  available  when  editing  concepts  in  KRENEE  is  the  macro  and  structure  editor.  This  view  iSee 
figure  5-1.)  provides  displav  and  editing  facilities  for  concept  definitions,  based  loosely  on  the  kind  of  structure 
editor  provided  in  mans  LISP  environments  The  view  provides  two  windows  for  the  display  of  stylized  defining 
forms  for  concepts  The  current  td:t  window  displays  the  definition  of  the  currently  edited  concept  (the  top  item  on 
the  editor  stack)  The  display  window  is  available  for  the  display  of  any  number  of  other  concepts  Any  concept 
which  is  visible  in  either  window  can  be  edited,  and  features  can  be  copied  from  one  concept  to  another  by  pointing 
Both  windows  are  scrollable  to  view  additional  definitions  as  required 

There  is  a  menu  of  commands  for  displaying  and  editing  definitions  that  includes  the  commands  Add  Structure. 
Change  Structure,  Delete  Structure.  Display  Concept  and  Clear  Display  Arguments  (it  any )  to  these 
commands  may  be  descnbed  by  poinung  or  typing.  Thus,  to  delete  a  slot,  one  simply  clicks  on  Delete  Structure 
and  the  display  of  the  slot  to  be  deleted  Adding  a  structure  is  done  by  clicking  on  Add  Structure,  the  keyword  ot 
the  feature  class  of  the  concept  one  w  ishes  to  add  to  (e  g  .  Slot:  i.  The  new  slot  itself  may  be  copied  from  a  displayed 
concept  by  pointing,  or  a  new  one  may  be  entered  from  the  keyboard  Changing  (that  is.  replacing)  a  structure  can 
be  done  by  pointing  in  succession  at  the  Change  Structure  command,  the  item  to  be  replaced,  and  the  thing  to 
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5.2  Developing  Macro  Editing  Procedures 

These  operations,  together  with  the  globally  available  commands  for  defining  new  concepts  and  making 
specializations  of  old  concepts  essentially  by  copying  their  definitions,  provide  an  extremely  flexible  environment  in 
which  to  define  and  specify  modifications  of  concepts  with  respect  to  other  defined  concepts.  Virtually  all 
knowledge  editing  operations  can  be  done  by  a  sequence  of  pointing  steps  using  the  current  edit  window  and  the 
display  window.  This  style  of  editing  is  also  used  in  the  rule  editor.  The  combination  of  editing  features  and 
mouse-based  editor  interaction  style  provides  an  extremely  versatile  environment  for  the  descnpdon.  by  example,  of 
a  large  class  of  editing  macros. 

In  order  to  have  macros,  defined  essentially  by  example,  work  on  concepts  other  than  those  for  which  they  were 
defined,  the  operations  recorded  cannot  refer  directly  to  the  concepts  or  objects  which  were  being  edited  when  the 
macro  was  defined.  This  is  handled  by  a  kind  of  implicit  variablization.  where  the  objects  named  or  pointed  to  are 
replaced  bv  references  to  their  relanonship  to  the  initially  edited  object.  In  most  cases,  these  indirect  references  can 
be  thought  of  as  references  to  the  location  of  the  object  in  the  structure  editor's  display  windows.  In  fact,  each  new 
object  that  is  displayed  or  edited  in  the  course  of  defining  a  macro  is  placed  on  a  stack  called  the  macro  items  list. 
together  with  a  pointer  to  the  command  that  caused  the  item  to  be  display  ed.  The  utility  of  this  form  of  reference 
will  become  clearer  with  an  example. 

5.2.1  Macro  Example:  Adding  Pipes  Between  Components 

When  the  STEAMER  [21]  system  was  dev  eloped,  a  structural  model  of  a  steam  plant  was  created  to  represent  each 
component  in  the  steam  plant  as  a  frame,  with  links  to  all  functionally  related  components  (e  g  .  inputs  and  outputs  i 
represented  as  slots  pointing  at  those  other  objects.  So.  for  example,  a  tank  holding  water  to  be  fed  into  a  boiler  tank 
through  some  pipe  that  was  gated  by  a  valve  was  represented  as  a  frame  with  an  OUTPUT  slot  whose  value  was  a 
VALVE.  The  OUTPUT  of  that  VALVE  was  a  BOILER-TANK.  The  pipes  through  which  the  water  w  as  convey  ed 
were  not  represented  since  they  had  no  functional  value  in  the  simulation  model.  If  it  had  become  important  to 
model  the  pipes,  e  g  because  they  introduced  friction  or  were  susceptible  to  leaks  or  explosions,  then  the 
representational  model  that  STEAMER  relied  on  would  have  required  massive  revision  Each  component  object  in 
the  system  would  have  needed  editing  to  replace  the  objects  in  its  INPUT  and  OUTPUT  slots  with  new  frames 
representing  pipes  that  were  in  turn  connected  by  their  OUTPUT  slots  to  the  next  component  in  the  system 

One  of  our  goals  in  developing  the  KREME  macro  editor  w  as  to  be  able  to  make  such  changes  easily  While  they 
are  simple  to  describe,  they  normally  require  many  tedious  editing  operations  to  a  large  number  of  concepts  Figure 
5-2  shows  a  macro  that  can  be  applied  to  all  objects  in  a  system  with  INPUT  and  OUTPUT  slots,  in  order  to 
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While  Editing  TANK1: 

Click  on  Define  Macro.  (Makes  Macro  hem  0  =  TANK1 ). 

1.  Make  a  new  concept  which  specializes  PIPE.  (Creates  PIPED  as  item  ]). 

2.  Change  the  INPUT  value  resmcnon  of  item  1  (PIPEO)  to  item  0  ( TANK1 ). 

3.  Change  the  OUTPUT  value  restncnon  of  item  1  (PIPEO)  to  the  OUTPUT  value  restriction  of  item  0 
(OUTPUT  of  TANK}  =  V ALVEI). 

4.  Classify  the  current  edit  concept  (Defines  PIPEO). 

5.  Change  the  OUTPUT  value  restncnon  of  item  0  (=  VALVE] )  to  item  1  (PIPEO). 

6  Classify  item  0  ( TANK!  t. 

7.  Edit  the  OUTPUT  value  restncnon  of  item  1  (Creates  item  2  =  VALVE!). 

8.  Change  the  INPUT  value  restncnon  of  item  2  ( INPUT  of  \  ALVEI  =  TANK} )  to  item  1  (PIPED). 

9  Classify  all  items 

Figure  5-2:  Steps  in  PIPE  Macro 


generate  and  insert  PIPEs  into  those  slots  The  macro  also  sets  the  OUTPUTS  of  those  PIPEs  to  be  the  concept  that 
was  the  old  value  of  the  OUTPUT  slot  in  the  concept  edited,  and  similarly  redoes  all  INPUTs 

Figure  5-2  shows  how  the  macro  is  defined,  by  edinng  a  representation  of  a  tank  (TANK1)  connected  (by  role 
OUTPUT)  to  a  valve  (VALVE2).  The  sequence  of  steps  required,  defined  only  using  the  mouse,  is  shown  in  figure 
5-2,  as  they  would  appear  in  the  Macro  Definition  window  of  the  editor. 

In  Phase  One,  work  on  macro  edinng  was  only  just  begun.  However,  this  technique  already  shows  promise  as  a 
method  for  accomplishing  restructurings  of  know  ledge  We  see  our  investigation  of  macro  editing  as  only  the  first 
step  in  developing  a  knowledge  reformulation  facility  that  will  make  use  of  the  higher  level  structure  of  the 
represented  know  ledge 
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6.  Knowledge  Integration  and  Consistency  Maintenance 

One  of  the  most  time  consuming  tasks  in  building  large  knowledge  bases  is  maintaining  internal  consistency. 
Modification,  addition  or  deletion  of  knowledge  in  one  part  of  a  knowledge  base  can  have  wide  ranging 
consequences  to  both  the  meaning  and  structure  of  the  knowledge  stored  in  other  parts  of  the  knowledge  base  A 
central  component  of  the  KREME  system  design  was  that  it  incorporate  tools  for  consistency  maintenance  both 
within  and  across  representation  languages.  These  tools  are  collectively  referred  to  as  the  knowledge  integrator. 
When  new  knowledge  is  entered  or  existing  knowledge  modified  it  is  the  task  of  the  knowledge  integrator  to 
propagate,  throughout  the  knowledge  base,  the  changes  that  this  new  or  modified  knowledge  entails,  and  to  repon 
any  inconsistencies  that  have  been  caused  by  the  change 

In  essence,  the  knowledge  mtegrator  takes  each  new  or  changed  chunk  of  knowledge  (e.g  .  a  frame,  role,  rule  or 
procedure)  and  determines,  first,  how  the  new  definition  fits  into  the  knowledge  base  and.  second,  which  other 
definitions  depend  on  the  current  one  for  their  meaning  within  the  know  ledge  base.  These  dependencies  are  placed 
on  an  agenda  which,  in  turn,  causes  them  to  go  through  essentially  the  same  process. 

The  knowledge  iniegrauon  subsystem  for  frames  is  basically  an  exteasion  of  the  classification  algonthm  developed 
for  the  N1KL  representation  language.  The  NIKL  classifier  correctly  inserts  nen  frames  into  their  proper  spot  in  a 
taxonomy,  by  finding  the  most  specific  set  of  concepts  whose  definitions  subsumed  the  definition  of  the  new 
concept  The  KREME  classifier  w  as  designed  to  additionally  allow  existing  concepts  and  roles  to  be  modified  and 
and  then  reclassified,  so  that  the  effects  of  redefinitions  are  automatically  propagated  throughout  the  entire  frame 
network.  This  was  accomplished  b>  redesigning  the  original  NIKL  classifier  to  lake  advantage  of  the  meta-le\el 
desenpuons  of  KREME  Frames  and  implementing  the  new  classifier  using  the  dependency  directed  agenda 
mechanism  of  the  overall  know  ledge  integrator. 
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6.1  The  Frame  Classifier 

The  remainder  of  this  section  will  give  a  brief  description  of  the  frame  classification  part  of  the  knowledge 
integrator,  which  is  the  most  completely  developed  portion  of  the  system  For  a  formal  descnption  of  the  NDCL 
classifier  algorithm  see  [14,  15].  For  a  more  complete  description  of  a  somewhat  simpler  classifier  for  an  editing 
environment,  see  [1], 

The  frame  classifier  works  in  essentially  two  stages,  starting  from  a  concept  or  role  definition,  as  supplied  by  the 
editor  or  read  from  a  file.  The  first  stage,  called  completion,  refers  to  the  basic  inhentance  mechanism  used  by 
KREME  Frames  to  install  all  inherited  features  of  a  concept  or  role  in  its  internal  description.  The  completion 
algorithm,  when  given  a  set  of  defined  parents  and  a  set  of  defined  features  for  an  object  determines  the  full, 
logically  entailed  set  of  features  of  that  object  The  second  stage  is  the  actual  classification  or  reclassification  of  a 
role  or  concept.  That  is.  the  determination  of  the  complete,  most  specific  set  of  parents  of  the  object  in  its  respective 
subsumption  hierarchy. 

i 

i 

|  6.1.1  Completion 

\  The  completion  algorithm  is  broken  up  into  modular  chunks  that  correspond  to  the  decomposition  of  the  frame 

I 

|  language.  There  is  a  disnnct  component  that  deals  with  slot  inheritance,  another  component  that  deals  with  disjoint 

\  class  inheritance,  a  third  that  deals  w'ith  slot  equivalence  inheritance  and  so  on.  This  organization  makes  it  quite 

straightforward  to  extend  the  language  with  new  features  that  handle  inheritance  in  different  ways. 

j  Figure  6-1  shows  some  of  the  complexities  of  slot  inhentance.  In  6-1  A.  the  most  specific  value  restriction  for  the 

slot  LIMBS  at  4-LEMBED-ANIMAL  is  inhented  from  one  parent  (ANIMAL)  while  the  most  specific  number 
restriction.  EXACTLY  4.  is  inhented  from  4-LIMB ED-THJNG  The  completion  algonthm  determines  that  the 
restriction  for  the  role  LIMBS  at  the  concept  4-LIMBED- ANIMAL  must  be  EXACTLY  4  LIMBS 

Figure  6-1B  shows  one  case  for  which  the  effective  value  restriction  must  logically  be  the  conjunction  of  several 
concepts.  Since  ANIMAL- WTTH-LEGS  is  both  an  ANIMAL,  and  a  THING- WITH-LEGS,  all  of  its  LIMBS  must 
be  both  ORGANIC-LIMBs  and  LEGs  If  the  concept  ORGANIC-LEG,  specializing  both  ORGANIC-LIMB  and 
LEG.  exists  when  AN1MAL-WITH-LEGS  is  being  classified,  the  integrator  will  find  it  and  make  it  the  value 
restriction  of  the  slot  LEGS  at  ANIMAL-WITH-LEGS.  If  it  does  not  exist,  the  integrator  stops  and  asks  if  the  user 
would  like  to  define  it  (that  is,  define  a  concept  that  is  both  an  ORGANIC-LIMB  and  a  LEG). 
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6.1.2  Classification 

The  second  stage  of  the  frame  classification  algorithm  finds  all  of  the  most  specific  subsumers  of  the  concept  being 
defined  of  redefined  This  is  the  actual  classification  stage,  and  is  essentially  a  special-purpose  tree  walking 
algorithm 

The  basic  classifier  algorithm  takes  a  completed  definition  (that  is,  a  definition  plus  all  its  effective,  inhented 
features)  and  determines  that  definition's  single  appropriate  spot  in  the  lattice  of  previously  classified  definitions 
The  result  of  a  classification  is  a  unique  set  of  the  most  specific  objects  that  subsume  the  definition  and  a  unique  set 
of  the  most  general  objects  that  are  subsumed  by  the  definition.  When  the  classified  definition  is  installed  in  the 
lattice  all  the  concepts  that  subsume  its  features  will  be  above  it  in  the  lattice  and  all  the  concepts  that  are  subsumed 
by  its  features  will  be  below  it 

The  classifier  is  built  around  a  modularly  constructed  subsumption  test  that  compares  the  completed  sets  of  features 
of  two  objects.  The  object  being  classified  is  repeatedly  compared  to  other,  potentially  related,  objects  in  the  latuce 
to  see  whether  its  completed  definition  subsumes  or  is  subsumed  by  those  other  objects  For  one  defimnon  to 
subsume  the  other,  its  full  set  of  features  must  be  a  subset  of  the  features  of  the  other.  As  with  completion, 
subsumption  tesnng  is  partitioned  by  feature  type  (i.e  slot,  disjoint-class  etc).  One  object  subsumes  the  other  when 
all  of  its  individual  feature-type  subsumption  checks  return  EQUIVALENT  or  SUBSUMES,  and  there  is  at  least  one 
vote  for  SUBSUMES  The  advantage  of  this  kind  of  modular  organization  is  extensibility.  If  a  new  feature  type  is 
added  to  the  language  one  need  only  define  a  subsumption  predicate  for  that  feature  and  objects  having  that  feature 
will  be  appropriately  classified. 

6.2  An  Example  of  Reclassification 

The  power  of  frame  reclassification  in  an  editing  environment  can  be  illustrated  with  the  following  relatively  simple 
example.  Suppose  a  knowledge  base  developer  had  defined  both  GASOLINE-POWERED-CAR  and  INTERN  AL- 
COMBUSTION-POWERED-CAR  as  specializations  of  CAR.  but  had  inadvertently  defined  INTERNAL- 
COMBUSTION-ENGINE  as  a  kind  of  GASOLINE-ENGINE  In  this  situation,  the  classifier  would  deduce  that 
INTERNAL-COMBUSTION-POWERED-CAR  must  be  a  specialization  of  GASOLINE-POWERED-CAR.  as 
shown  in  figure  6-2A,  since  the  former  restricted  the  role  ENGINE  to  a  subclass  of  the  larter  s  restriction  of  the 
same  role 

Redefining  INTERNAL-COMBUSTION-ENGINE  as  a  kind  of  ENGINE  (rather  than  a  GASOLINE-ENGINE  i.  and 
then  reclassifying,  causes  all  of  INTERNAL-COMBUSTION-ENGINE  s  dependents  to  also  be  reclassified. 
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Figure  6-2:  An  Example  of  Reclassificaoon 


B.  After  Reclassification 
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including  INTERN  AL-C0MBUST10N-P0WERED-CAR  Since  GASOLINE-ENGINE  no  longer  subsumes 
INTERNAL-COMBUSTION-ENGINE,  the  restrictions  for  GaSOLINE-POWERED-CAR  no  longer  subsume  those 
of  INTERNAL-COMBUSTION-POWERED-CAR,  and  the  classifier  therefore  finds  that  GASOLINE-POWERED- 
CAR  does  not  subsume  INTERNAL-COMBUSTION-POWERED-CAR.  This  is  shown  in  figure  6-2B. 


The  combination  of  inconsistency  detection  during  the  completion  phase  and  the  automatic  propagation  of 
classification  changes  that  occurs  during  reclassification  makes  KREME  a  powerful  and  extremely  useful  tool  for 
knowledge  base  development  and  refinement.  Since  the  effects  of  reclassification  are  immediately  made  apparent  to 
users  via  the  dynamically  updated  graph  of  the  subsumption  lattice,  they  sometimes  find  that  the  definitions  they 
have  provided  have  some  unanticipated  logically  entailed  effects  on  their  taxonomy.  Sometimes  these  effects  are 
surprising,  although  correct.  Other  times,  they  lead  to  changes  and  additions  which  make  the  knowledge  base  more 
complete  and  correct. 


6.3  Using  the  Knowledge  Integrator  to  Partition  and  Merge  Knowledge  Bases 

6.3.1  Load  Merge 

Perhaps  the  single  most  important  use  for  the  Knowledge  Integrator  is  to  enable  orderly  merging  of  independently 
developed  knowledge  bases.  The  process  of  loading  one  knowledge  base  into  another  is  made  somewhat  involved 
by  the  need  to  merge  and/or  split  and  rename  concepts  that  have  the  same  name  in  both  networks. 

There  are  a  number  of  complex  cases  to  deal  with.  The  simplest  case  occurs  when  two  defimuons  of  the  same 
concept  have  different  but  complementary  attributes.  The  KREME  merge  logic  simply  forms  the  union  of  the 
attributes  of  both  concepts  and  edits  all  pointers  to  either  concept  so  that  they  point  to  the  new  .  ennched  concept 
(See  Figure  6-3. ) 

A  somewhat  more  complex  case  occurs  when  slots  shared  by  both  concepts  are  given  different  restrictions.  (See 
Figure  6-4.  i  The  system  chooses  the  most  spectfic  restriction  for  the  slot 

If  concepts  with  the  same  name  have  properties  that  make  it  impossible  to  merge  them  —  that  is.  the  identical  names 
really  stand  for  different  concepts  in  the  two  knowledge  bases  1 6-5  >.  then  the  system  will  inform  the  user  of  this  fact 
and  ask  the  user  for  a  new  name  for  one  concept 

The  user  has  some  control  over  this  entire  process  and  can  set  switches  which  cause  the  svstem  to  alw  as s  quer\ 
when  it  finds  two  concepts  with  the  same  name,  always  merge  concepts  if  it  can.  or  never  merge  concepts,  keeping 
the  know  ledge  bases  distinct 
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6.4  Saving  and  Partitioning  Knowledge  Bases 

Any  time  during  the  development  of  a  knowledge  base,  the  user  can  save  the  entire  developing  knowledge  base  to  a 
disk  file.  This  is  a  useful  feature  when  developing  small  knowledge  bases  or  working  on  a  piece  of  a  knowledge 
base  that  will  later  be  merged  into  a  larger  whole. 

Another  useful  facility  is  KREME's  ability  to  partition  a  knowledge  base  along  user-designated  lines  and  save  the 
partitions  in  distinct  files.  This  is  accomplished  by  allowing  the  user  to  designate  a  set  of  seed  concepts.  KREME 
will  then  create  and  save  a  partition  of  the  entire  knowledge  base,  based  on  the  seeds.  In  an  oversimplifed  sense,  the 
partition  consists  of  the  seeds,  all  specializations  of  the  seeds,  and  all  the  concepts  that  the  seeds  either  directly  or 
indirectly  depend  on.  This  facility  can  be  used  to  break  up  a  single  knowledge  base  into  several  overlapping 
subcomponents. 

6.5  Using  Merge  and  Partition  to  Build  Larger  Knowledge  Bases 

Taken  together,  the  merge  and  partition  facilities  suggest  an  approach  that  we  think  will  prove  to  be  an  extremelv 
powerful  paradigm  in  the  building  of  very  large,  very  complex  knowledge  bases.  When  a  knowledge  base  grows  to  a 
size  at  which  it  becomes  difficult  to  deal  with  in  its  entirety,  the  partition/save  facility  can  be  used  to  divide  it  into 
several  overlapping  logical  subcomponents,  each  of  which  is  a  full  scale,  consistent  knowledge  base  in  its  own  right 

These  multiple,  smaller  knowledge  bases  can  be  w  orked  on  independently  of  each  other  with  full  confidence  that  the 
loader/merger  can  put  the  independently  built  subcomponents  together  in  an  orderly,  consistent  fashion 

In  Figure  6-5.  there  are  two  networks.  The  ball '  in  Network  1  stands  for  a  concept  that  is  a  kind  of  round  object.  In 
Network  2.  the  name  "ball'  stands  for  a  land  of  formal  dance  These  are  differenct  concepts  with  unmergeable 
properties.  In  both  networks.  Event  and  Object  would  be  defined  to  be  disjoint.  In  this  case,  the  Merger  would  ask 
the  user  for  a  new-  name  for  one  of  the  concepts  and  would  keep  them  distinct. 
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7.  Editing  Behavioral  Knowledge 

KREME  embodies  a  set  of  mechanisms  for  representtng  and  editing  behavioral  knowledge  One  mechanism 
involves  associating  behaviors  with  frames.  Since  frames  can  also  be  associated  with  pa~nrs.  behaviors  have  been 
implemented  so  that  they  can  be  compiled  into  flavor  methods 

A  click  of  a  mouse  button  and  the  tabular  features  window  in  the  mam  concept  wen  is  turned  into  the  toplevel 
behavior  editor.  All  behaviors  currently  defined  for  the  concept  are  shown  Each  has  3  name  and  a  type  There  are 
three  types  of  behaviors  currently  allowed;  Rules.  Procedures,  and  Methods  Existing  behaviors  can  be  edited  or 
new  ones  defined.  A  modified  form  of  the  Symbolics  favor  examiner  can  be  accessed  to  show  various  useful 
informanon  about  method  combination  and  derivation. 

Methods  are  simply  flavor  methods.  Editing  a  method  throws  up  a  text  editor  window  which  can  be  interacted  with 
in  normal  editing  style  or  in  structure  editing  sty  le  Editing  or  inputting  a  new  rule  packet  accesses  the  Rule  Editor 
Editing  or  inputting  a  new  procedure  accesses  the  Procedure  Editor 

7.1  Editing  Rules 

The  rule  language  used  by  KREME  is  a  language  called  FLEX  [16],  based  in  large  pan  on  the  LOOPS  rule 
language.  FLEX  allows  rules  to  be  defined  in  rule  packets,  which  organize  sets  of  rules  that  are  meant  to  be  run 
together  In  the  KREME  environment,  rule  packets  can  be  attached  to  concepts,  just  as  if  they  were  functional 
methods  In  addition,  they  may  be  inherited  by  more  specialized  concepts  FLEX  incorporates  a  mechanism  for 
dealing  with  uncenainty,  based  on  EMYCIN  [19]  The  FLEX  runtime  environment  also  provides  an  elementary 
history  and  tracing  mechanism,  and  an  explanation  system  that  produces  pseudo-English  explanations  from  rule 
traces.  For  efficiency,  FLEX  also  provides  a  means  for  rule  packets  to  be  compiled  as  LISP  code,  and  run  without 
the  rule  interpreter  present 

The  KREME  rule  editor  is  built  on  top  of  the  KREME  structure  editor.  One  defines  and  edits  rules  by  specifying 
and  filling  out  portions  of  rule  templates.  The  user  refine  these  templates  either  by  using  the  mouse  to  copy  parts  of 
existing  rules  or  by  pointing  at  slots  to  be  filled  and  typing  in  the  desired  values.  Once  a  rule-set  has  been 
developed,  the  rule  editor  provides  commands  to  run  packets  and  debug  them  It  can  also  generate  traces  or  rule 
histones  paraphrased  in  pseudo-English  Mechanisms  are  also  provided  for  deleting  and  reordering  rules,  and 
loading  and  saving  them  from  files  The  rule  editor  is  show  n  in  figure  7- 1 
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The  rule  editor  is  also  tied  to  the  KREME's  knowledge  integration  subsystem  At  present,  ail  references  to  slots  of 
frames  made  in  rules  are  checked  for  validity  by  the  knowledge  integrator.  If  invalid,  the  user  is  alerted  and  may 
switch,  if  necessary,  to  editing  the  associated  frame.  If  the  problem  was  simply  that  he/she  named  a  non-existent 
slot,  a  valid  one  may  be  selected  from  a  menu.  In  the  near  future,  the  knowledge  integrator  will  also  check  such 
cross-references  in  the  opposite  direction,  as  when  a  slot  referred  to  by  some  rules  is  deleted  or  changed  in  the  frame 
editor. 

KREME  at  present  edits  rules  in  the  FLEX  [16]  rule  language  In  FLEX,  rules  come  in  rule  packets,  and  the 
KREME  Rule  Editor  edits  an  entire  packet  at  one  time  Rule  packets  provide  a  way  to  organize  rules 

The  forward  chaining  rule  packets  come  in  four  varieties,  indicating  the  type  of  control  mechanism  used  for  rule 
firing 

•  do- 1 -rule-packets  execute  the  first  rule  whose  test  „acceeds. 

•  do-all-rule-packets  execute  all  rules  whose  tests  succeed 

•  while- 1  -rule-packets  repeatedly  test  all  rules,  finng  one.  until  no  tests  succeed. 

•  «hile-all-ruie-packets  repeatedly  fire  all  rules  whose  tests  succeed,  until  none  succeed 

Rule  packets  are  connected  to  KREME  frame  sy  stents  or  other  data  contexts  by  specifying  an  access  en\  ironmert 
An  access  environment  is  an  object  that  receises  messages  dealing  with  the  accessing  of  values  for  references  in  the 
rules  It  handle'  all  messages  to  get  or  set  the  values  of  variables  and  their  confidences. 

7.2  The  KKKMK  Rule  Editor 

Rules  are  defined  and  edited  by  specifying  and  tilling  out  portions  of  rule  templates.  To  refine  these  templates 
either  use  the  mouse  to  copy  parts  of  existing  rules  or  point  at  slots  to  be  filled  and  type  in  the  desired  values. 

There  are  also  commands  to  run  packets  and  debug  them  and  to  generate  traces  or  rule  histones  paraphrased  in 
pseudo-English,  and  delete  rules  and  reorder  rules,  and  load  and  save  rules  from  tiles. 
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branching  or  iteration;  the  mechanisms  for  procedural  abstracoon.  specialization,  and  path  or  reference 
reformulation  that  formed  the  heart  of  the  language  seemed  to  form  the  kernel  of  an  extremely  useful 
representational  facility. 

The  KREME  representation  language  family  includes  a  descendant  of  the  STEAMER  procedure  language,  built 
using  KREME's  library  of  knowledge  representation  primitives.  Each  KREME  procedure  has  a  name,  a 
description,  an  action  that  the  procedure  is  meant  to  accomplish,  a  list  of  steps,  and  a  list  of  ordering  constraints  that 
determine  the  partial  ordering  of  the  steps.  Steps  have  an  action  and  an  object  which  names  the  conceptual  class  of 
things  that  step  acts  upon.  Procedures  are  attached  to  specific  frames  and  can  be  "compiled"  into  flavor  methods. 

Each  step  in  a  procedure  may  either  be  a  primitive  action  or  another  procedure.  If  the  object  of  a  step  defines  a 
procedure  for  the  action  of  that  step  then  this  procedure  is  said  to  be  a  sub-procedure  of  the  enclosing  procedure 
For  example,  the  ALIGN  procedure  attached  to  the  concept  SUCTION-LINE  could  have  a  step  ALIGN  <PLMP>  If 
the  concept  CENTRIFUGAL-PUMP,  w  hich  is  the  object  of  this  step  for  SUCTlON-LINEs.  defined  a  procedure  for 
the  action  ALIGN,  then  the  step  ALIGN  <PUMP>  could  be  expanded  into  the  steps  of  the  procedure  for  aligning  a 
centrifugal  pump 

7.4.1  Procedural  Abstraction  and  Structure  Mapping 

For  knowledge  acquisition  purposes,  it  would  be  very  useful  if  procedures  were  represented  in  an  abstracuon 
hierarchy  like  that  for  frames  In  a  strong  sense,  it  seems  difficult  to  define  exactly  what  it  means  for  one  abstract 
procedure  to  subsume  another  However,  from  an  acquisition  standpoint,  much  power  can  be  gained  by  allowing 
abstract  procedures  to  form  templates  upon  which  more  specific  procedures  can  be  built,  and  eventually  providing 
tools  for  automatic  plan  refinement  like  those  found  in  NOAH  (13]  For  example,  if  you  have  some  idea  about  how 
to  grow  plants  in  general,  and  you  want  to  grow  tomatoes,  you  will  use  your  knowledge  about  growing  plants  in 
general  as  a  starting  point  for  learning  about  growing  tomatoes.  The  final  procedure  for  growing  tomatoes  will 
include  some  (presumably  more  detailed i  versions  of  steps  in  the  more  general  procedure,  and  may  also  include 
steps  that  are  analogous  to  those  used  in  grow  mg  other  plants  for  which  more  detailed  knowledge  exists.' 

The  KREME  Procedures  editor  has  a  mechanism  for  building  templates  of  new  procedures  out  of  more  abstract 
procedures.  When  a  new  procedure  is  being  defined  at  a  concept,  the  procedural  abstraction  function  determines 
whether  any  of  that  concept  's  parents  have  a  procedure  for  accomplishing  the  same  action.  If  so,  an  initial  procedure 
template  is  built  by  combining  the  steps  and  constraints  of  all  the  inherited,  more  abstract  procedures  The  paths 


’For  i  detailed  discussion  of  related  issues  see  Carbonell  [4]  on  deris  ational  analoeua]  planning 
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(objects)  of  the  steps  are  adjusted,  using  the  concept's  slot  equivalences,  to  use  "local"  slot  names,  as  much  as 
possible,  As  yet  this  facility  does  not  have  the  ability  to  do  detailed  reasoning  with  constraints  on  steps,  as  NOAH 
does.  We  expect  to  greatly  expand  this  capability  during  Phase  Two  of  the  project. 
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8.  Knowledge  Extension 

One  task  faced  by  knowledge  engineers  is  getting  experts  to  express  generalizations  about  their  domains  of 
expertise.  While  much  of  the  detailed  information  about  particular  problems  can  be  accessed  and  represented  by 
looking  at  specific  examples  and  problems,  the  expert’s  abstract  classification  of  problem  types  and  the  abstract 
features  he  uses  to  recognize  those  problem  types  are  less  directly  available.  Experienced  knowledge  engineers  are 
often  able  to  discover  and  define  useful  generalizations  which  experts  perceive  as  relevant  to  their  own  reasoning 
processes.  The  experts  may  then  suggest  improvements,  related  generalizations,  or  more  abstract  generalizations 

Our  initial  experiment  in  knowledge-base  extension  in  Phase  1  has  been  the  development  of  a  frame  generalization 
algorithm.  Our  current  generalize!  finds  potentially  useful  generalizations  by  searching  for  sets  of  concept  features 
that  are  shared  by  several  unrelated  concepts. 


When  the  generalizer  finds  a  set  of  at  least  k  features  shared  by  at  least  m  concepts,  where  k  and  m  are  user-settable 
parameters,  the  system  forms  the  most  specific  concept  definition  that  would  enclose  all  of  the  features  but  would 
still  be  more  general  than  any  concept  in  the  set.  Since  our  simple  algonthm  has  no  other  external  notion  of 
"interestingness'  it  simply  displays  this  potential  new  concept  defimuon  to  the  user.  For  example,  given  three 
concepts  that  are  all  ANIMALS  and  independently  define  the  slot  WINGS,  the  generalizer  would  suggest  forming  a 
specialization  of  ANIMAL  with  the  slot  WINGS,  that  these  concepts  would  all  specialize.  If  the  user  wanted  to 
introduce  this  concept,  he  would  respond  by  naming  the  new  generalization  (e  g..  FLYING- ANIMAL  I.  w  hich  w  ould 
then  be  classified  and  integrated  with  the  network  The  features  that  are  enclosed  by  this  new  .  more  general 
concept,  are  automatically  removed  from  each  of  the  more  specific  concepts  being  generalized. 
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7.3  The  Rule  Editor  View 

Many  of  the  windows  in  the  Rule  Editor  View  should  be  familiar  by  now.  The  complete  list  is  as  follow  s 

1.  Global  Command  Window  displays  global  commands  that  can  be  selected  by  the  user  In  this 
example,  the  user  has  used  the  mouse  to  select  Edit  Packet  The  user's  selection  is  highlighted 

2.  State  Window  displays  the  name  of  the  packet,  the  network  it  is  associated  with,  and  other  useful 
information. 

3.  Editor  Stack  Window  displays  the  names  of  the  items  recently  edited  and  some  information  on  their 
current  state.  Items  in  the  editor  stack  window  can  be  selected  for  editing  with  the  mouse 

4.  Behavior  Command  Window  is  a  menu  of  commands  that  apply  to  Rules  and  Rule  Packets 
(Behauor  is  another  term  for  rule  packets,  or  functional  methods  on  instances  of  concepts  > 

5.  Current  Edit  Item  Window  displays  the  item  that  has  been  selected  for  editing 

6.  Dispay  Related  Items  W  indow  allows  the  user  to  view  other  rule  packets  and  scroll  through  them 
Rules  and  parts  of  rules  can  be  copied  from  the  Scroll  Window  into  the  Current  Edit  Item  Window 

7.  Editor  Interaction  Window  displays  screen  prompts  and  user  input  The  user's  edits  are  made  in  this 
window  and  then  displayed  in  the  Current  Edit  Item  Window 

8.  Related  Behaviors  Window-  displays  an  index  of  other  mle  packets  that  are  related  to  the  one 
currently  being  edited.  With  the  mouse,  the  user  can  rapidly  scroll  through  this  index  and  select  a 
related  rule  packet  for  viewing  or  editing 

To  get  into  the  Rule  editor  use  the  New  Packet  or  Edit  Packet  command  ir  the  global  command  window 


Thereafter,  the  structure  editor  can  be  used  m  much  the  same  way  the  Macro  Structure  Editor  is  used  to  edit 
concepts  The  Rule  Structure  Command  Menu  contains  the  commands 

•  Define  Behavior  is  similar  to  Classify  Concept.  It  makes  the  definition  of  the  packet  permanent,  and 
allows  it  to  be  run  or  attached  to  a  concept 

•  Similar  Behavior  -  Creates  a  packet  with  the  same  niles.  etc  but  gives  it  a  new  name,  and  present  it  to 
be  edited  to  make  it  different. 

•  Kill  Behavior  -  Kills  the  definition  of  this  packet. 

•  Display  Packet  -  Displays  the  packet  in  the  Display  of  Related  Items  Window 


When  a  whole  rule  packet  is  outlined,  the  user  can  choose  to  Edit  Packet  CL:),  or  (R:)  choose  from  a  menu  of  Edit 
Packet.  Edit  Basis  or  Display  Lisp  Form 

Other  editing  commands  are  found  on  the  keywords  and  component  pieces  of  packets  and  rules.  For  instance, 
clicking  left  on  Rule:  places  a  new  (empty)  rule  in  the  packet,  which  can  then  be  filled  out  by  clicking  on  IF  to  add 
a  new  condition  (condiuons  are  treated  as  pan  of  a  conjunction)  or  THEN  to  add  a  new  action.  Clicking  nghi  gives 
a  menu  of  Add  (Empty  Rule).  Copy  One  Rule  from  somewhere  else  into  this  packet,  and  Copy  Rule  Set  which 
copies  all  of  the  rul^  from  another  packet 

Clicking  over  Type:  gives  the  user  a  choice  of  the  standard  types  of  rule  packets,  described  above 
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Packet  Classes:  allows  the  user  to  specify  a  flavor  to  be  mixed  into  the  packet  Arguments:  and  Return 
Variables:  each  allow  the  user  to  add  a  new  one  (L: )  or  choose  from  a  menu  of  Add  One.  Add  Several.  Edit  and 

Replace. 

When  a  whole  rule  is  outlined,  clicking  left  will  be  replace  the  rale  with  another  rule  that  the  user  points  at 
Clicking  right  gives  a  menu  of  Replace  Rule,  Edit  Attributes  and  Delete  Rule 

Whenever  expressions  appear  (after  the  word  Precondition:,  or  as  parts  of  conditions  or  actions),  the  user  may 
Replace  the  expression  (L:),  or  choosing  from  a  menu  (R)  of 

•  Replace  the  expression  with  another  one. 

•  Edit  the  expression  as  text. 

•  Delete  the  expression 

•  Add  Before  another  expression  (copied  from  somewhere  by  pointing) 

•  Add  After  another  expression 

•  Exchange  two  expressions  positions. 

•  Parenthesize  a  set  of  expressions  together 

•  Deparenthesize  an  expression  into  piecies. 

•  Evaluate  the  expression  in  the  current  context. 

7.4  Procedures  in  the  KREME  Environment 

An  obvious  weakness  of  many  knowledge  representation  languages  is  their  inability  to  handle  declar3tively 
expressed  knowledge  about  procedures  as  partialh  ordered  sequences  of  actions,  particularly  if  that  knowledge  is 
represented  at  multiple  levels  of  abstraction  Although  a  number  of  systems  have  been  developed  that  do  vanous 
forms  of  planning.  [5.  12,  13.  18],  most  have  not  encoded  their  plans  in  an  entirely  declaranve  or  inspectable 
fashion  Certainly  the  current  generation  of  expert  system  tools  does  not  provide  mechanisms  geared  to  the 
description  of  this  kind  of  knowledge  Although  it  is  clear  that  much  of  an  expert's  knowledge  about  a  domain  is 
about  procedures  and  their  application,  little  work  has  been  done  on  devising  ways  to  capture  that  information 
directly. 


The  STEAMER  project  [21]  began  to  address  the  issue  of  declarative  representanons  for  procedures  in  the  course  of 
developing  a  mechanism  to  teach  valid  steam  plant  operating  procedures  The  representation  system  developed  for 
this  task  had  to  be  directly  accessible  to  the  students  who  were  the  system  's  users,  and  it  had  to  serve  as  a  source  of 
explanations  when  errors  were  made  STEAMER  was  able  to  describe  these  procedures,  decompose  them,  show 
how  they  were  related  to  similar  procedures  and.  in  general  deal  with  them  at  the  '  knowledge  level  [10]  rather  than 
as  pieces  of  programs  or  rule  sets  Although  the  syntax  of  the  language  w  as  quite  primitive,  with  no  provisions  for 
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9.  Conclusion 


The  goal  of  the  BBN  Laboratories  Knowledge  Acquisition  Project  is  to  build  a  versatile  experimental  computer 
environment  for  developing  and  maintaining  large  knowledge  bases.  We  are  pursuing  this  goal  along  two 
complementary'  paths.  First,  we  have  constructed  a  flexible,  extensible,  Knowledge  Representation,  Editing  and 
Modeling  Environment  in  which  different  kinds  of  representations  (initially  frames,  rules,  and  procedures)  can  be 
used.  We  are  now  using  this  environment  to  investigate  acquisition  strategies  for  a  variety  of  types  and 
combinations  of  knowledge  representations.  In  building  and  equipping  this  "sandbox  ',  we  have  been  adapting  and 
experimenting  with  techniques  which  we  think  will  make  editing,  browsing,  and  consistency  checking  for  each  style 
of  representation  easier  and  more  efficient,  so  that  knowledge  engineers  and  subject  matter  experts  can  work 
together  to  build  with  significantly  larger  and  more  detailed  knowledge  bases  than  are  presently  practical. 

The  second  aspect  of  our  research  plan  is  the  development  of  more  automatic  tools  for  knowledge  base 
reformulation  and  extension  An  important  part  of  this  endeavor  is  the  discovery ,  categonzation  and  use  of  explicit 
knowledge  about  knowledge  representations:  methods  for  viewing  different  knowledge  representations,  techniques 
for  describing  knowledge  base  transformations  and  extrapolations,  techniques  for  finding  and  suggesting  useful 
generalizations  in  developing  knowledge  bases,  semi-automatic  procedures  of  eliciting  know  ledge  from  experts,  and 
extensions  of  consistency  checking  techniques  to  provide  a  mechanism  for  generating  candidaie  expansions  of  a 
know  ledge  base 

We  are  attempting  to  provide  a  laboratory  for  experimenting  with  new  representation  techniques  and  new  tools  for 
developing  knowledge  bases.  If  we  are  successful,  many  of  the  techniques  developed  in  our  laboratory  will  be 
adopted  by  the  comprehensive  knowledge  acquisition  and  knowledge  representation  systems  required  to  suppon  the 
development  and  maintenance  of  future  AI  systems. 
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10.  Appendix  A:  Test  Plan 


10.1  Loading  KREME  from  Cassette  Tape 


Each  site  can  test  KREME  by  loading  KREME  from  tape  according  to  the  directions  in  this  Appendix  and 
then  editing  the  sample  nerworks  provided  on  the  tape  Once  KREME  has  been  loaded,  the  document  KREME  d 
User's  Introduction  BBN  Report  No  6508  provides  instructions  on  how  to  edit  and  create  knowledge  bases  using 

KREME 

KREME  requires  a  Symbolics  machine  with  Genera-'  0  already  installed  and  with  at  least  18000  blocks  free 
m  its  FEP.  If  your  machine  has  no  tape  drive,  you  will  have  to  read  the  tape  on  another  machine  that  does  have  one 
and  then  transmit  the  bands  to  your  machine  (See  section  10  }We  will  use  the  terms  destination  machine  and  tape 
drive  machine  to  refer  to  these  two  machines  Note  that  you  must  have  at  least  18000  blocks  free  on  the  desanation 
machine's  FEP  as  well  as  having  at  least  18000  blocks  free  on  the  FEP  of  the  machine  w  ith  the  tape  dnve 

10.1.1  Loading  the  FEP  Files 

There  are  four  FEP  Files  on  the  tape  'lour  machine  mav  already  have  inc-7-0Gl-from-Genera-7-0.load  If 
so,  do  not  create  a  FEP  file  for  that  file  and  do  not  load  tt  from  the  tape 

Log  in  to  the  machine  and  create  three  (or  four)  FEP  files  in  the  following  wav 

Create  FEP  Tile  inc-7-0Gl-from-Genera-7-0 . load  1290 
Create  TEP  Tile  inc-BBN-f rom-inc-genera-7-0Gl . load  5600 
Create  FEP  File  Kreme-Crom-Boot7 . load  9580 
Create  FEP  File  Kreme . boot  1 

Log  out  and  halt  the  machine 

Put  the  FEP  Files  tape  in  the  tape  dnve 

Type  the  following  to  the  FEP 
scan  V127-disk 

(This  teaches  the  FEP  about  disk  restore  i  Then  type 

disk  restore 

The  machine  will  then  ask  if  you've  done  Set  Disk  Type  Answer  Y1  The  machine  then  asks  if  you  want  to  restore 
the  FEP  files  on  the  tape  In  each  case  answer  Y  and  press  carnage  return  t If  you  already  have  the  first  band  on  your 
system,  answer  N  for  that  band  >  In  each  case,  the  system  will  then  prompt 


If  the  disk  is  ne*  and  has  not  been  initialized  see  your  local  system  wizard 
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file  to  restore? 

Accept  the  default  file  name  by  pressing  carnage  return 

The  machine  displays  numbers  as  it  reads  from  the  tape  The  machine  then  asks  about  the  other  files  in  turn 
Each  time,  answer  Y  to  restore  the  file  and  then  press  carnage  return  to  accept  the  default  file  name 


10.1.2  Editing  the  FEP  Files 

Now  you  must  edit  the  file  Kreme  boot  to  set  the  CHAOS  address  correctly  To  do  this,  boot  the  machine 
(using  a  boot  file  other  than  Kreme  boon  and  edit  Kreme.boot  Change  the  line  containing  the  CHAOS  address  to 
set  it  to  the  address  of  the  destination  machine  You  can  get  the  correct  CHAOS  address  for  the  destination  machine 
from  the  system  manager  or  by  looking  at  the  address  in  another  boot  file  on  the  destination  machine 

You  must  also  edit  the  Load  Microcode  line  in  Kreme  boot  so  that  it  contains  the  number  of  the  microcode 
version  on  the  host  To  determine  that  number,  ask  the  system  manager  or  look  at  a  boot  file  that  boots  a  7.0  uorld 

Now  log  out  and  halt  the  machine 

10.1.3  Booting  KREME 

Type  ihe  following  to  the  FEP 

Boot  Kreme . boot 

Because  the  band  is  being  booted  at  a  site  other  than  the  site  at  which  it  was  built,  the  machine  w-iil  ask  you  if 
the  site  is  still  BBN  Answer  NO  and  the  machine  will  name  itself  DIS-LOCAL-HOST 

If  the  machine  has  identity  problems  (It  thinks  it  is  still  at  BBN  i.  the  simplest  way  to  deal  with  them  is  to 
unplug  the  ethemet  before  booting  Kreme  boot  See  your  local  system  wizard  if  you  want  a  more  elegant  solution 

Once  the  boot  is  complete,  you'll  have  a  KREME  window  with  the 

KREME: 

prompt.  Now  get  to  a  Lisp  Listener  era 

<»alact>L 

Then  log  in  with  the  command 

(*i : login- to-sys -host ) 

Logging  in  in  this  way  avoids  interacting  with  the  BBN  system  accounong  software  Then  load  the  carry-tape  with 
the  command 

(tape : carry-load) 

The  carry-tape  contains  two  sample  KREME  networks,  mech-net  lisp  and  org- net  lisp  You  will  have  to  choose  a 
place  on  your  machine  to  store  these  files 
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You  are  now  ready  to  use  KREME  with  the  help  of  KREME  .A  i'ser's  Introduction.  Try  loading  a  sample 
network  from  one  of  the  files  you  read  off  the  carry -tape. 


10.2  For  Machines  with  No  Tape  Drive 


First,  load  the  FEP  Files  from  the  tape  onto  the  tape  drive  machine  by  following  the  instructions  in  section 
10.1.1.  Then  boot  that  machine,  using  a  boot  file  other  than  Kreme.boot  Then  transmit  the  FEP  Files  to  the 
destination  machine  by  typing  the  following  to  a  Lisp  Listener.  (Answer  Y  when  the  system  asks  if  you  really  want 
to.) 

(si : transmit -band  " fapO : >inc-7-0Gl- f rom-gensra-7-0 . load" 

desn  nation -machine) 

(si  :  transmit -band  "  fepO  :  >inc-bbn-  f  rom-inc-genera-7-0  .  load'' 

desn  nation -machine) 

(si : transmit-band  "fepO : >Kreme-f rom-boot7 . load" 

desn  nation -machine) 

Copy  Fila  fepO  :  >Kreme  .  boot  destination-machine  1  fepO  :  >Kreme  .  boot 


You  are  now  finished  using  the  machine  with  the  tape  dme  You  may  delete  the  KREME  files  on  that 
machine  before  going  to  the  destination  host 

Now  connnue  with  the  instructions  in  section  10  1.2 
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